Star diagrams: Designing abstractions out of existing code

Reengineering an existing legacy system into an object-oriented system often requires encapsulating existing data structures and converting computations on the data structures into method calls. This design task requires an architect to understand how the current data structures work in detail, then perform global changes to the source code to instantiate the new class. Various systems help the architect identify global data structures that are good candidates for encapsulation. Some tools[6, 8] help the programmer partition and modularize an existing system by graphically representing interactions between components. Others use metrics and similarity measures to identify likely boundaries between objects [9, 11]. Once the architect decides a data structure should be represented by an object in the new system, the architect must choose the operations for accessing and manipulating it. The architect may have enough domain knowledge to deduce the appropriate methods for familiar data structures such as dates, or can use plan libraries [10] to automatically identify common abstractions. What will happen when the architect cannot assume how the data structure is manipulated? When functions in the original system map directly into methods of the new system, an architect can manipulate function-level diagrams of the system to restructure the system. However, if the new methods must be created from computations not already abstracted away as functions, choosing the methods requires understanding of common calculations performed on the abstraction, not just how blocks of the system relate. Rather than a top-down remodularization of the system, the task becomes a bottom-up creation of new methods. Building up methods for a new class from computations on an existing data structure requires four steps. None are well supported in current tools. Identifying all the uses of a data structure being encapsulated. The architect needs to identify all the computations on the data structure. While the source code contains all the needed information, it also provides a significant amount of information unrelated to computations on a given data structure, obsfuscating the data structure’s relationships to the rest of the program. A text searching tool like grep [2] provides assistance in locating direct references, but its lexical and line-based orientation yields false matches, includes irrelevant information, misses surrounding context, and misses cases such as indirect reference through assignment. Grouping similar computations on the data structure. The architect must understand the range of calculations on the data structure, and know which uses are common and uncommon. Repeated computations may represent common abstract operations on the data structure. grep identifies the uses, but it does not show the similarities among computations, nor assist in the actual manipulation. (See Figure 1). Planning the task. The architect needs assistance with the task of choosing functions, then modifying the source code. Without tool support, a programmer must methodically search to identify all computations on the data structure and keep careful records of what should be changed, or otherwise risk performing an ill-planned encapsulation. In particular, the scattering of references can encourage a programmer to make interface design decisions locally. Methods created early-on could be at a different “level of abstraction” than methods discovered later, resulting in badly-designed objects. Submission for OOPSLA ’96 Workshop: Transforming Legacy Applications into Object-Oriented Applications. This work was performed jointly with Dr. W. G. Griswold, Computer Science and Engineering Department, University of California, San Diego.